Often transactions are authenticated between a user and an entity by the user providing that entity with a password or PIN which is in principle known only to the user and the entity. A problem with such authentication arrangements is that the password or PIN may become known to an unauthorised person, who may then be able to illegitimately perform transactions which appear to the entity to be requested by the user.
It is known to improve such authentication arrangements by using so-called “one-time” or “dynamic” passwords that are valid for only a predetermined time interval, typically one minute or less, or are used only once. With such an arrangement, even if the password or PIN is intercepted, the interception of the password or PIN will not facilitate illegitimate performance of transactions after the password or PIN has expired at the end of the predetermined time period.
One such known arrangement is RSA SecurID® authentication. With this system a user is provided with a “token”, which may be a hardware or software component that is assigned to a particular user and which generates an authentication code using an algorithm at fixed time intervals (for example, every minute). Such tokens include a random key that is specific to the user (known as a “seed”), which random key is also known to a RSA SecurID server. The random key is typically 128 bits long. A hardware token typically includes an LCD display which displays the authentication code, which is generated using the random key, and that is valid for the current one minute time period.
If the token is a hardware token, it will typically include a tamper resistant built-in clock which is used to determine the time intervals at which a new authentication code should be calculated. If the token is a software token, then typically access to a time source will be provided in order to determine the time interval for calculating each new authentication code. The time may be provided by Network Time Protocol (NTP), for example.
When a user wishes to perform a transaction, such as accessing a remote server, to perform the authentication, the user provides a user ID, a password or PIN, and the authentication code displayed at the moment of login on the display of the securID token. The user ID and password or PIN are checked by the remote server and the authentication code is provided to the securID server for validation. The securID server includes its own real-time clock (which is effectively synchronised with the clock of the token) and a database of valid securID tokens and their random key/seed. The secure ID server uses the same algorithm as the secure ID token to compute what the authentication code should be at that moment in time, and then determines whether the authentication code that it has calculated corresponds with the authentication code provided by the secure ID token and transmitted via the remote server. If the authentication codes match, then the secure ID server indicates to the remote server that authentication has been completed satisfactorily. Access to the remote server is allowed if the user ID, password/PIN and the authentication code match the expected values.
Whilst a secure ID token provides a relatively secure arrangement for authenticating transactions, it does require the user to carry the authentication token with them at any time at which they may wish to perform a transaction. Some users find this inconvenient.